In three-tier networked topologies, the middle layer acts as a concentrator for many clients to share a finite resource at the back-end service. It can be used to protect the back-end systems by providing a level of indirection and hence a point of control.
In a highly available three-tier system, the middle tier can add further value by providing a single point of entry to client applications, thus hiding the complexity of the middle-tier and back-end implementation, both of which may be made up of multiple cloned nodes.
When the middle tier itself is made up of multiple cloned nodes, ultimately—one of those nodes will be elected to process a specific request. In certain circumstances, the middle-tier node, having received a specific request, might find that it is unable then to satisfy the request (e.g. within a target response time). This might occur if the selection of the specific middle-tier node coincides with a problem in the back-end node associated with this specific middle-tier node.
Having exhausted any chance to successfully process the request, the middle-tier node would typically respond to the client application associated with the request with an error. The client would then close and re-open its connection to the middle tier, in the expectation that an alternative middle-tier node would be selected.
An example of such a highly available three-tier system is a transaction system in which client applications access transaction servers via a transaction gateway. An example of such a transaction system is the IBM CICS® Transaction Server System (CICS is a trade mark of International Business Machines Corporation).
An external call interface (ECI) request is typically received and processed by a single gateway daemon. The path length and network resources used to successfully connect to and deliver an ECI request to a gateway daemon form a large “investment” in terms of response time, and CPU (Computer Processing Unit) load. Unfortunately, the successful delivery of an ECI request to a gateway daemon does not guarantee a successful onward delivery of the request to its intended destination (for example, a transaction server). This might be due to a temporary lack of capacity between the gateway daemon and transaction server, for example, all communication resources are busy.
Such failures can result in the entire connection from application to gateway daemon being torn down and subsequently being re-established, with the expectation that the new connection will deliver the request to an alternative gateway daemon, which does have the capacity to service the request. This failover pattern is an expensive process.
Therefore, there is a need in the art to address the aforementioned problems.